Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000126_owner-urn-ietf _Wed Oct 30 15:46:54 1996.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA04945 for urn-ietf-out; Wed, 30 Oct 1996 15:46:54 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA04938 for <[e-mail]>; Wed, 30 Oct 1996 15:46:52 -0500
Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA17107  (mail destined for [e-mail]); Wed, 30 Oct 96 15:46:50 -0500
Received: from carlyle.ncsa.uiuc.edu (carlyle.ncsa.uiuc.edu [141.142.230.144]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with ESMTP id OAA08495 for <[e-mail]>; Wed, 30 Oct 1996 14:21:29 -0600
Received: from ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by carlyle.ncsa.uiuc.edu (8.6.11/8.6.9) with ESMTP id OAA26648 for <[e-mail]>; Wed, 30 Oct 1996 14:21:27 -0600
Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id OAA12250; Wed, 30 Oct 1996 14:15:51 -0600 (CST)
Date: Wed, 30 Oct 1996 14:15:51 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Message-Id: <[e-mail]>
To: Ron Daniel <[e-mail]>
Cc: [e-mail]
Subject: [URN] HTTP resolution protocol
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

(Why are people putting [URN] in the title if the recipients are
all on the urn-ietf list?  Just curious.)

Ron Daniel writes:

 >          Conventions for the Use of HTTP for URN Resolution

Perhaps the whole document could be more specific on the fact that
this is a particular kind of URN resolution, not the only way that
HTTP might in fact be used (simultaneously) for URN resolution.
For example, path URNs can be mapped directly to http URLs, which
the client resolves normally via HTTP, using whatever services are
supported via HTTP.  (Additional http services might be metadata
requests, for example.)

 > Abstract:
 > =========
 >
 > One of the main purposes of the work on URNs is to allow resources
 > to be replicated onto multiple sites.

I disagree with this.  Replication should be considered orthogonal to
naming and name resolution.  Names are not required to offer just as
much transparency in the replication process and resolution via
replicas.  An identifier (whether a "name" or "location") for a
resource can be associated with many other identifiers of replicas, or
alternatively, an identifier can be associated with many other
services that *have* replicas of the resource.

The main purpose of URNs is to provide an additional level indirection
via a relatively long lived resolution service (e.g. DNS).  Providing
replica identifiers at the same time as providing this indirection
seems like a reasonable thing to do (and it is) but it is the
indirection which is the main purpose of names.

You also have described several other services that the server would
provide, so why focus on replication in the Abstract?

 > Obtaining a copy of such a
 > replicated resource procedes by contacting a "resolver" that knows the
 > locations of the replicated resource.

An HTTP server could know the locations of a replicated resource
identified by either an http URL or a URN.


 > 2.0 General Approach:
 > =====================
 >
 > The general approach used to encode resolution service requests in HTTP
 > is quite simple:
 >
 >     GET <service>/<uri>  HTTP/1.0
 >
 > For example, if we have the URN "cid:[e-mail]" and want a URL,
 > we would send the request:
 >
 >     GET N2L/cid:[e-mail] HTTP/1.0

What you propose works, but consider why not do:

  N2L cid:[e-mail] HTTP/1.0

The "N2L/" prefix on the URI defines a name space within the server -
the server might be used for other things simultaneously.  Doing a GET
request on this URI means (in current HTTP) that the result should be
cachable, and as far as the client is concerned it looks like
"N2L/whatever" is the identifier for a resource itself.  The full URL
for this resource is "http://wherever/N2L/whatever".  Could we then
request "N2L/N2L/whatever"?

With a new "N2L" method, things would be different.  Whether the
result is cachable is not certain.  Most servers cannot (yet) be
configured to handle new methods.  But otherwise, it might make more
sense to keep the N2L service request out of the identifier of the
real resource (the <whatever>).  Folding the service (or method) request
into an identifier is not a sin - in fact, I have suggested more of
the same.  I just want to point out that that is what you are doing.

 > One caveat should be kept in mind. The "urn:" prefix is still the
 > subject of controversy, so some URN documents advocate treating it
 > as optional. HTTP resolvers MUST return identical results for URIs
 > that do and do not contain the "urn:" prefix.

Wouldn't it be simpler just to require that the "urn:" should be
removed before submitting the request?

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/